Method and system for configuration control in telecommunications networks

ABSTRACT

The configuration of telecommunications-network elements is controlled by first generating a model configuration of the elements comprising, for at least one function of each element subjected to control, a respective model of implementation of the function itself. For each element subjected to control, at least one respective set of configuration data of the element itself is collected and, again for each element subjected to control and in the absence of interaction with the element itself, correspondence is verified between the one function as implemented on the basis of the at least one respective set of configuration data of the element and the model of implementation of the function itself included in the model configuration. These steps of generating, collecting and verifying are done relative to an interfacing element between two nodes of the plurality or a plurality of respective sets of configuration data of the element.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the US national phase of PCT applicationPCT/EP2003/008702, filed 6 Aug. 2003, published 4 Mar. 2004 as WO2004/019556, and claiming the priority of Italian patent applicationTO2002A000742 itself filed 23 Aug. 2002, whose entire disclosures areherewith incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to controlling the configuration of thevarious elements (nodes, interfaces between nodes, etc.) included in atelecommunications network and in particular relates to the possibleaccomplishment of a centralized function for controlling theconfiguration of a telecommunications network, such as a mobiletelecommunications network. Nonetheless, the uses of the invention arenot limited to this specific application.

BACKGROUND OF THE INVENTION

In general, the activities of controlling and designing theconfiguration data of a telecommunications network are particularlycomplex and delicate.

Among the reasons for the complexity of the activities, the followingcan be recalled:

-   -   most interventions in the network, such as the insertion of a        new node (for instance, the so-called MSC/VLR of a mobile radio        network), the introduction of a new service or the maintenance        of an existing service generally implies the need to        define/redefine the data pertaining to the new/pre-existing        nodes;    -   given the possible centrality of a node within the network        architecture (again considering the example of a MSC/VLR of a        mobile radio network), the erroneous definition of configuration        data of a node and of the criteria for interaction with the        nodes destined to co-operate with the node itself can lead to        deleterious effects in terms of service availability and        possible consequent loss of revenues;    -   in a network, even a small sized one, a great quantity of        configuration data is present which, in addition to being        delicate and having strategic value, are subject to being        updated very frequently, and    -   the activities of designing and/or configuring the nodes and the        other elements of the network are generally carried out (even        when the nodes are based on the same technology) at different        times by different subjects.

Wholly identical functions can therefore be implemented according toequivalent but not exactly identical principles and criteria, givingrise—within the network—to a lack of uniformity which is alwaysnegative; this also taking into account the fact that, in any case,different network operators have the tendency to integrate in the samenetwork nodes and/or node components based on different technologies.

It is therefore necessary to provide network operators with suchinstruments as would enable them to:

-   -   ensure that the configuration data of the operating facilities        comply with the rules set out by the network operators in the        technical design standards,    -   standardize the configuration of the systems thanks to the        identification, on one hand, of the configuration data destined        to be identical for all systems and, on the other hand, of the        data that cannot be, given their dependence on the location of        the system within the network;    -   optimize the performance of the systems, identifying and        eliminating any redundancies in the configuration data, and    -   unite in a single entity the function of defining the reference        configuration rules, leaving to other entities (possibly        distributed over the territory if the network is a large one)        the action of verifying whether the configuration of the nodes        complies with the rules.

In this regard it should be noted that there is a strong interdependenceamong the various categories of the configuration data; therefore, it isnecessary to have instruments available to check the effects due to thevariation of the generic data category: a typical example regardsnumbering analysis, which is strongly interdependent with billinganalysis.

There is also a strong implicit interdependence between theconfiguration data of different nodes in the network. In other words,the correct treatment of a service within each network node consideredindividually fails to guarantee in absolute fashion the correctoperation of the service within the network in its entirety. Designconfiguration choices on the individual network nodes, which inthemselves may be functionally correct, may in fact be foundincompatible when the nodes are interfaced. When verifying the operationof network services or performance, oftentimes there are no absolutecorrectness criteria to be applied to the individual node, but it isnecessary to use correctness criteria relating to the operation of theother nodes in the network.

For instance, it is known among those skilled in the art that an errorin a configuration data item in one node can cause malfunctions in thenetwork services that manifest themselves only outside the node itself.The node whereon an error is observed is not always responsible for themalfunction. Therefore, it is necessary to obtain instruments that havethe capability of checking the behavior induced on the network by theconfiguration data, both at the level of the individual node and at thelevel of the entire telecommunications network in which the node isinserted.

In addition, the semantic distance between the punctual configurationdata item and the effect it has on the behavior of the network can bevery large. The network operator can detect an error in a configurationdata item but not be able to estimate its severity; conversely, he mayobserve an undesired behavior in the network but not be able todetermine which error in a configuration data item in a node may havecaused it.

Therefore, it is important to have instruments available that are ableto offer a vision both of the global high level behavior of a networkservice, and to perform a low level analysis of the individualconfiguration data item in a specific node, aiding the user insemantically connecting the different levels of detail of the analysis.

Traditional techniques for checking the correctness of configurationdata are generally based on the preventive manual checking of sets ofcommands containing modifications to configuration data, on checksthrough software tools of compliance with the correct syntax of theconfiguration commands, or on making test calls to test the properoperation of the service downstream of the transmission of theconfiguration data in the network.

These techniques do not allow one to identify in a wholly satisfactorymanner possible errors in the configuration data, either because theyare too costly in terms of time and resources or because they are notexhaustive. For example, very often modifications to configuration dataare made during the night time hours under conditions of light networkloading. Tests conducted in this network condition may not be exhaustivesince, under conditions of heavier loading, the network may for instanceperform different routings following second or third choice routingpaths because of the saturation of the main routing due to intensetraffic. It is therefore important to provide network operators withinstruments that are able to give answers as to the correctness ofconfiguration data more accurately and exhaustively than those that canbe obtained with traditional techniques and in compliance with the timelines required for activating network services.

In view of the deleterious consequences of errors in the configurationdata, it is advisable on one hand to be able to perform checks prior toupdating data in the network and on the other hand to extend thechecking action passing from a mere function of analysis andverification to a function of (re) designing the configuration data ofthe nodes in accordance with predetermined rules.

OBJECT OF THE INVENTION

The object of present invention is to provide a solution able toovercome the limitations set out above and to meet the requirementsdescribed previously in a wholly satisfactory manner.

SUMMARY OF THE INVENTION

According to the present invention, this object is achieved thanks to amethod having the characteristics specifically described below. Theinvention also relates to the corresponding system as well as thecorresponding computer program product able to be directly loaded intothe internal memory of a digital computer and comprising portions ofsoftware code to implement the method according to the invention whenthe product is run on a computer.

BRIEF DESCRIPTION OF THE DRAWING

The invention shall now be described, purely by way of non limitingexample, with reference to the accompanying drawings, in which:

FIG. 1 shows, in the form of a functional block diagram, the possiblearchitecture of a control system, integrated in a mobile radio network,operating according to the invention,

FIG. 2 shows, in the form of a functional block diagram, a configurationcheck being performed in a system according to the invention,

FIGS. 3 through 5 show some examples of data structures involved in thecheck of FIG. 2,

FIG. 6 shows, in the form of a functional block diagram, a functionalcheck being performed in a system according to the invention,

FIGS. 7 through 9 show some examples of data structures involved in thecheck of FIG. 9,

FIG. 10 shows the structure of the functions with which the node can bemodeled for the simulation aims of the invention,

FIG. 11 shows an example of functional analysis carried out in a systemaccording to the invention,

FIG. 12 shows, in the form of a functional block diagram, the executionof a functional check involving the node state simulation component in asystem according to the invention,

FIG. 13 shows, also in the form of a functional block diagram, theexecution of an analysis at the level of the entire network using theinterface/protocol simulator, and

FIG. 14 shows, again in the form of a functional block diagram, theapplication of the various techniques described also to a possiblefuture configuration built by applying only in the simulated environmenta set of commands for modifying the current configuration.

SPECIFIC DESCRIPTION

In the currently preferred embodiment, the solution according to theinvention allows one to implement a set of techniques that allow,adopted either separately or in mutual combination, to manage and checkthe configuration data of the elements included in a telecommunicationsnetwork. This providing in particular the ability to simulate thebehavior of the network nodes and of other elements of the network inthe absence of interaction with the elements subjected to checks.

In particularly advantageous fashion, the characteristic elements of thesolution according to the invention are able to coexist and co-operatewith more traditional control techniques.

A first example in this regard is given by the configuration controltechnique aimed at verifying the configuration of the data of the node,comparing it with a reference standard.

To achieve this type of control in a system of the type illustratedherein, typically the configuration data in operation are drawn from oneor more files associated with the node (commonly called printouts) andthe data in operation are compared with the reference data.

This first technique is simple to implement, as it requires to comparethe equality of two sets of data without making any simulation of thebehavior, for instance, of the nodes. Each discrepancy between the datameasured in a node and the reference data constitutes an error in theconfiguration data, which can be removed by generating a packet ofmodifications to the configuration data such as to make them identicalto the reference.

This solution is suitable to solve data standardization problems.However, it is not—in itself—suitable to meet all indicatedrequirements: to be effective, the reference standard must be at thesame level of detail as the configuration data; moreover, this type ofchecks is not applicable when the set of data to be checked does nothave the objective of being (or cannot be) identical in all nodes in thenetwork; lastly, there is no immediate correlation between the errordetected in the configuration data and its consequences on the operationof the service and on the performance of the network.

Another technique is instead based on the simulation of the behavior ofthe functions of the node by means of so-called “functional checks” withthe goal of verifying the operation of the node by comparing theemulated behavior with the behavior specified by the reference standard.

In this regard it should be recalled that in general a network node isconstituted by a set, which can be quite complex, of co-operatingfunctions.

For example, there are functions that manage:

user profile analysis,

calling numbers and called numbers analysis,

signaling routing analysis,

call routing analysis,

call billing analysis, and

end of selection analysis.

To each functionality are generally associated one or more configurationfiles (with known format, called node printouts) that indicate thevalues of the parameter of the functionality itself.

It is possible to request from the generic node the configuration of thefunctionality of interest starting from the so-called printout.

To allow functional checks, software functions (called “analyzers”) arespecified and realized, and each simulates the individual functionalityof the node.

For example, with reference to call management, analyzers are used tosimulate called numbers management, signaling routing, call routing,etc.

From the analysis of the global operating specifications of the node,procedures destined to exploit the aggregation of the analyzers tosimulate the function of the node are specified. the procedures thusallows one to simulate a whole series of global behaviors of the node.

To simulate the execution of the generic procedure, the following inputdata are used:

-   -   the configuration data in operation of the analyzers associated        with the procedure and obtainable from the corresponding node        printouts, and    -   the input parameters for the global procedure.

The check verifies that the expected operation coincides with thatobtained by executing the procedure for the node of interest.

To enable the user to simulate in step-by-step mode the generic functionof the node, an environment is defined that allows one to:

select the node of interest,

select the analyzer of interest,

configure the input data to the analyzer, and

simulate the function in step-by-step mode.

This technique offers a solution that overcomes many of thedisadvantages of the prior art. Comparing the expected and observedbehaviors in a node by means of the simulation carried out with theanalyzers, it is no longer necessary for the reference to be expressedat the same level of detail as the configuration data; moreover, it isnot the equality of the data with respect to the reference that ischecked, but rather the behavior which data induce on the node. Thismakes the technique effective even in contexts in which theconfiguration data do not have the objective of being (or cannot be)rendered identical on all systems. Moreover, since it is a check with agreater semantic content than that of the prior art, the correlationbetween the error detected in the configuration data and itsconsequences on the operation of the service and on the performance ofthe network is easier.

To the techniques described previously, the solution according to theinvention allows one to add more advanced techniques, better describedhereafter.

Some analyzers can lead to more than one possible analysis result,whereof only one is followed each time by the node in its actualbehavior. The choice made by the node depends on the instantaneousconditions of the network.

One can take, by way of example, the analysis of routings for a networkservice: a call directed to a number can be routed, for the same finaldestination, following different paths, each with different priority,depending on the loading condition of the paths at the time of routing.

In the currently preferred embodiment, the invention provides for theintroduction of a new simulative element that takes into account allpossible analysis results corresponding to different possible states ofthe node, in order to use the results to obtain the simulation of theexhaustive behavior of the node, i.e. independently from the particularinstantaneous network conditions.

With respect to the prior art, this development allows one to overcomethe limitation given by the non exhaustive nature of the technique thatcalls for the execution of manual call tests conducted during night timehours (which verify the proper operation of the service only in theparticular case of unloaded network), considerably increasingreliability and allowing an exhaustive simulative approach toconfiguration data management with respect to traditional techniques.

An additional enhancement is obtained by introducing a new element thatis able to simulate the interaction between one node and the next in thetraffic path.

This element serves as a simulator of the component useful for analyzingthe interwork at the interface between the network nodes. For example,it simulates the network protocol interfaces used for signalingexchanging or call routing purposes (“interface/protocol simulators”).This new element allows one to pass from the simulation of the behaviorof a node to the simulation of the overall behavior of the network incase of a particular service or performance.

To allow the user to simulate the complete behavior of the network,based on the configuration data present for a certain service in thenetwork, an environment is defined that allows one to:

-   -   select a traffic scenario and a starting system, setting        determined initial conditions of the simulation;    -   visualize all possible alternatives obtained by simulating the        different nodes and the different interfaces that in any network        condition will lead to the rendering of the service given the        initial conditions set.

The coexistence of this technique with all techniques illustratedpreviously in the same instrument enables the user to fill the semanticdistance between the punctual configuration data and its effect on thebehavior of the network, offering both a vision of the high level globalbehavior of a service in the network, and the possibility to carry out alow level analysis of the individual configuration data item in aspecific node, aiding the user in semantically connecting the differentlevels of detail of the analysis.

An additional simulative element allows one to apply to a configurationdetected in the network a set of commands for modifying theconfiguration itself in the simulated environment alone, leading to anew version of the configuration data set for a single node or even forthe entire network. On this new version of the configuration, all priortechniques can be applied.

This new simulative element therefore allows one to apply all priortechniques not only to the verification of existing configuration data,but also to the data consequent to a set of appropriate configurationcommands applied to the existing configuration before their actualinsertion in the network node.

This technique can be used effectively together with the prior ones indesign as well as control activities to provide a sort of analysis ofthe impact in the network of the introduction of a certain set ofmodifications to the configuration data, highlighting any errors andconsequent degraded services before their actual introduction into thenodes constituting the actual environment.

Moving now to a detailed examination the accompanying drawings, in FIG.1 the reference N globally indicates a telecommunications networkrepresented—in the application example whereto (without thereby limitingthe scope of the invention) reference shall constantly be madehereafter—by a mobile radio network. FIG. 1 schematically shows variousMSC/VLR (Mobile Services Switching Center/Visitor Location Register) andHLR (Home Location Register) elements, connected, through a data networkRD1, to respective management systems, respectively indicated as k−1, k,k+1.

As stated, although the solution according to the invention wasdeveloped in view of its possible application to controlling theconfiguration data of a mobile radio network, reference to the possibleapplication must not be construed as limiting the possible scope of theinvention, which is altogether general.

The general structure and nature of the network can be any. This holdstrue in particular for the structure and the interconnection modes ofthe various nodes included therein. Specifically, the fact that threemanagement systems are represented, distinguished by the references k−1,k and k+1 is purely by way of example and is in no way destined toexpress a connection or sequential constraint of any sort existing amongthe systems.

This stated, referring (again by way of example) to a mobile radionetwork, within the network nodes particular relevance is assumed by themanagement systems . . . , k−1, k, k+1, . . . typically called OMC(Operation and Maintenance Center). Here are collected the files (callednode printouts) with the configuration data of the network nodes.

For the purposes of the present invention, it will be sufficient torecall that the configuration data characteristic of each node in thenetwork are usually organized in the form of ASCII files that may residein the management system . . . , k−1, k, k+1, . . . and are thereforeable to be collected at the level of a data base DB destined toconstitute the heart of the server S of the system according to theinvention.

The collection of the files containing the configuration data of eachnetwork node can be carried out by the server S remotely, for instanceaccording to the typical transmission modes of a data network (RD2).

Consequently, within the data base DB residing in the server S (orotherwise available to the server S itself) a portion of data base isdedicated, indicated as DB1, in which are collected the configurationdata associated with the nodes, extracted from the configuration filesCFk−1, CFk, CFk+1 . . . drawn from one or more node printouts.

The persons versed in the art will appreciate that, although—for thesake of simplicity in the description—the files in question areindicated herein with generic subscripts . . . , k−1, k, k+1, . . . ,this designation must in no way be construed as indicative of acorrespondence between files and management systems. This is because,for instance, each system may manage several nodes, each with multiplefiles.

Another portion (indicated as M1) of the data base DB is dedicated tostoring the reference data or behaviors, used as a “model” for theentire network.

Otherwise stated, the model M1, depending on the technique used on eachoccasion, may represent: a set of configuration data that are to beidentical on all nodes of the network in configuration checks cases; aset of expected behaviors for a node in the case of functional analyses;a set of exhaustive behaviors of all nodes that can be traversed in thecase of simulation of a determined service over the entire network.

The model M1 is organized by a network manager that creates theconfiguration model M1 through its own work station W1 which interacts,at the local network level or remotely, with the server S.

The system represented herein allows, in the first place, to verify thatthe configuration data are all consistent (virtually identical to eachother, at least in the parts destined to be so, because they are notspecific of a particular node) and in any case in accordance with theconfiguration specifications defined by the “model” configuration.

FIGS. 2 through 5 respectively show the general diagram of the control,the model M1, the format of the configuration data and the type ofoutcome expected.

The diagram of FIG. 2 shows the criteria whereby, within the scope of asystem according to the invention, a configuration control is performedover the data relating to any functionality of the node.

In essence, the control corresponds to a verification function C carriedout by comparing:

-   -   configuration data corresponding to the standard (model M1),        able to have a structure of the type shown in 10 in FIG. 3, and    -   the actual configuration data corresponding to the data in        operation collected in the corresponding node printout and        having, in the representation format internal to the system, a        structure like the one shown in 12 in FIG. 4.

Starting from the comparison function indicated as C, the systemgenerates a report REP having the structure represented in 14 in FIG. 5.In practice, the report in question has a first has a first columnshowing an identifier of the configuration data item followed by asequence of pairs of parameters where the first is the reference dataitem (postfix N, i.e. Norm or standard) and the other one the parameterin operation (postfix D, i.e.

Data item in operation).

In this way, the report 14 allows one to highlight the following typesof out-of-alignment conditions:

-   -   data in operation in excess with respect to the reference;    -   missing data in operation with respect to the reference, and    -   different values of the parameters for the same configuration        data item.

In the currently preferred embodiment of the invention, the system isconfigured in such a way as to extend the control action beyond the merestep of verifying the actual situation. This is achieved by performing afunction of reconfiguring the nodes of the network, aimed at causing anyconfiguration data exhibit dismorphic characteristics with respect tothe data of the “model” to be modifiable to attain the desiredconforming condition. All proceeding with the reconfiguration of thenodes accomplished remotely, for instance by transmitting to themanagement system . . . , k−1, k, k+1, . . . of the node involved oneach occasion the commands and the data necessary to proceed with thereconfiguration.

It will be appreciated that this preferred mode of organizing the systemaccording to the invention allows one to perform a networkreconfiguration action. the action constantly assures that, forinstance, all nodes in the network are configured in mutually uniformfashion and in accordance with the reference specifications.

This operating mode allows constantly to follow the evolution of thenetwork deriving, for instance, from the addition of new nodes and/orfrom the addition (or elimination) of determined functions of one ormore nodes with the consequent reconfiguration of the entire network.

This, it should be observed, also when the nodes of the network are notall based on the same technology.

An important element of the solution described herein is given by theability to simulate (by means of corresponding functions) the genericfunctionality of the nodes. This allows one to avoid any invasive impacton the network nodes.

A node can generally be modeled as a set of co-operating functions.Within the scope of the solution described herein, functions thatreplicate the functions of the node have been defined and implemented.

The functions that emulate the generic functionality of the node aredefined in general-purpose fashion and the information required tosimulate the behavior of the functionality of the node of interest arerepresented by:

-   -   the input data for starting the function, and    -   the configuration data present in the node printout associated        with the functionality.

In this way it is possible to simulate the behavior of the genericfunctionality of the generic network node avoiding any invasiveintervention on the network N itself.

The solution according to the invention therefore provides for the aforethe verification to be performed by means of simulation according to thecriteria better described hereafter.

FIGS. 6, 7, 8, 9, 10 and 11 refer to the criteria with which, within thesystem according to the invention, are performed the functional checksdestined to verify that the expected operation of the node coincideswith the one obtained from the execution of the corresponding procedurefor the node of interest.

In essence, the solution described herein is based on the performance ofchecks that can be accomplished no longer by comparing the actualconfiguration with the reference configuration, but comparing the set ofexpected behaviors of the node with the actual behavior computed bymeans of functional analyses that use the simulative method.

The diagram of FIG. 6 shows the criteria with which, within the scope ofa system according to the invention, are based the functional checks ofthe data relating to any functionality of the node.

Within the network node, the configuration data present CNk are used bythe related functions and influence the behavior of the node itself.

The system described herein is able to acquire the configuration dataCFk extracted from the printouts and, by means of simulation modulescalled analyzers A, to simulate the behavior CSk that the node assumesas a consequence of the configuration itself.

Lastly, the control corresponds to a verification module CC thatoperates by comparing:

-   -   a set of expected behaviors (model M1), able to have a structure        of the type shown in 16 in FIG. 7, and    -   a set of simulated behaviors obtained as the result of the        functional analyses and having, in the representation format        internal to the system, a structure like the one shown in 18 in        FIG. 8.

Starting from the comparison function indicated as CC, the systemgenerates a report REPC having the structure represented in 20 in FIG.9.

In practice, the report in question has a sequence of pair of behaviorswhere the first behavior is the reference data item (postfix N, i.e.Norm or standard) and the other one is the simulated behavior (postfixS, i.e. Simulated). The diagram of FIG. 6 also shows additional functionblocks, indicated as FN and CRk, representative of the functions of thenetwork node corresponding to the configuration data CNk and to theactual behavior of the node in question.

The diagram of FIG. 10 shows the typical organization of a MSC/VLR of amobile radio network, which can be seen as a set of co-operatingfunctions destined to manage, for example, the calling numbers, thecalled numbers, signaling routing, call routing, call barring, callbilling and end-of-selection management. In essence, the solutionaccording to the invention is based on the creation, within the databaseDB, of a set of simulation functions at the software level, each ofwhich was built based on the set of rules and criteria with which adetermined node technology accomplishes a node functionality.

For example, they can be, with reference to the MSC/VLR case mentionedpreviously, of functions that at the software level emulate:

-   -   billing analysis (20),    -   analysis of the identifier called International Mobile        Subscriber Identity or IMSI (22),    -   signaling analysis (24),    -   call routing analysis (26),    -   calling number analysis (28), and    -   called numbers and barring analysis (32).

FIG. 11 shows the execution of the functional analysis carried outexploiting a register R which is nothing else than the set of variablesable to represent:

-   -   the input data of the first function in the chain,    -   the data obtained as a result of the generic function and able        to represent the input data for the subsequent function, and    -   the data obtained as the final result of the complete chain.

For example, FIG. 11 shows a typical functional analysis sequenceconducted in relation to checking the handling of the calls of users whouse the service called “International Roaming”.

In particular, the check is aimed at verifying a foreign GSM user'sability to complete a call directed to a number in his/her own countryof origin.

After from a list (step 100) the node, an IMSI number and a callednumber in the country of interest, and after introducing thecorresponding information in the register R, are activated in sequencethe analyzers corresponding to the respective functions of the networknode. In this case, the analyzers are activated in order for theanalysis of the IMSI identifier (step 102), the analysis of the callednumbers and of the barring (step 104) and the analysis of billing (step106).

It will be appreciated that the various analyzers exploit asconfiguration data:

-   -   the input data to activate the analyzer in the case it is the        first of the chain,    -   the input data obtained from an analyzer activated previously,        and    -   the configuration data obtained from the printout associated        with the analyzer.

FIG. 12 shows the conduct of a functional control involving the nodestate simulation component.

The simulator SS of the state of the node does not simulate an existingfunction of the real node but simulates the occurrence of the differentenvironmental conditions that would influence the result of theactivation of a functionality of the node and that may also influencethe invocation of the subsequent functions.

If for instance the result of the analysis of the routing of a certaincalled number leads to different possible solutions with alternativechoices depending on the actual state of the resource of the actualnode, the actual node would terminate the analysis following the onlychoice consistent with the actual state of the resources at thatinstant.

The simulator of the node state, instead, generates a set of possiblestates s1, . . . , sn each of which corresponds to a situation that maylead to a different result of the analysis. In the currently preferredembodiment of the invention, to the different states are associated asmany instance of the register R.

If the simulation continues downstream of the aforementioned analyzer,the simulation will have to be continued branching the analysis offstarting from the n behaviors deriving from each possible state. Thefinal result, therefore, is a set of simulated behaviors CS, k, sassociated to the node k in the state s.

In the execution of a check, the simulated behaviors are comparedthrough a decisional component CC to the possible expected behaviorsexpressed in M1. The result is, as in the previous cases, an REPC reportthat indicates the differences between the expected behaviors and thesimulated behaviors.

From the functional point of view, the set constituted by the analyzersA and by the simulator of the node state SS can also be considered anode simulator macro-block, called SN, destined to operate on theconfiguration data CFk extracted from the printout.

FIG. 13 refers to the criteria with which, within the system illustratedherein, are accomplished the functional checks destined to verify theexpected behavior of a service or of a performance of the network as awhole.

In essence, the solution described herein is based on operation checksno longer accomplished as described above on the individual nodes of thenetwork considered separately, but on the behavior of the nodes upontheir interfacing and of the interwork for the realization of theperformance or of the services.

The diagram of FIG. 13 shows the criteria for the execution of thefunctional checks of the network services.

In a generic network node k, the configuration data CFk extracted fromthe printouts are used by the related simulation functions SN of thebehavior of the node and influence the behavior of the node itself inthe rendering of the service.

It is then supposed that for the rendering of the service the node kinterfaces with the node k+1 by means of appropriate network protocols.

The system illustrated herein is able to simulate the rules for theinteraction and interface between the nodes by means of appropriatefunctions SIk/k+1, which then in turn enable the simulation of thebehavior of the node k+1 given the particular rendering of the servicewhich takes into account the behavior at the interwork that occurredwith the node k.

The final result is the behavior of the network CSN resulting from thebehavior of. the individual network nodes and, thanks to the simulativeinterfacing element SIk/k+1, from the mutual interwork that influencesthe behavior of the nodes themselves.

These simulated network behaviors can be compared to the expectednetwork behavior M1 from a decisional component CC. The result is, as inthe previous cases, a report REPC that indicates the differences betweenthe expected behavior and the simulated behavior.

FIG. 14 refers to the criteria with which, in the system describedherein, the previous techniques are applied to a future configurationnetwork instead of to the current configuration.

<COMMENT: Detail WHAT-IF Analysis>

This way of proceeding allows one to meet the requirement of performingdata checks before their actual introduction in the network, allowingthe analysis of the impact that a modification to the node configurationdata will bring to the behavior of a single node or of the network.

An element FC, able to simulate the command analysis functionality,allows one to apply to a configuration CF detected in the network andextracted from the printouts a set of commands CM to modify theconfiguration itself in the simulated environment alone, leading to anew version CFM of the configuration data for a single node or even forthe whole network. On this new version of the configuration can now beapplied all previous techniques.

This way of proceeding can be freely combined with the varioustechniques described above; therefore the new CFM configuration canrefer to a subset of the configuration data of a node, up to allconfiguration data of the nodes of the whole network. The newconfiguration can be analyzed simply through the analyzers, or besubjected to configuration checks, exhaustive functional checks, checksof the operation of a network service on all nodes and so on.

In the currently preferred embodiment of the invention, thecontrol/simulation functions are activated by a plurality of terminalsor work stations U1, . . . , Un distributed on the territory and able tointeract remotely with the system server S for instance with datanetwork RD3 communication modes. All this, with the stations U1, . . . ,Un usually being inhibited from interaction with the model configurationM1 whose definition is left exclusively to the station W1. This need todistribute the work stations U1, . . . , Un over the territory is feltless acutely if the system is configured in such a way as to be able toaccomplish in centralized fashion also the (re) configuration of thenodes starting from a single control station. In this latter case, it isalso possible merge in a single station (such as the station W1) thefunctions of general network supervision and of starting the simulationfunctions. In the diagrams of FIG. 1 the functions are instead shown tobe attributed in distinct fashion to the station W1, on one part, and tothe stations U1, . . . , Un, on the other part.

Each of the stations U1, . . . , Un is usually able to perform at leastthe following operations:

-   -   finding the current configuration of a node or of multiple nodes        by importing their printout, and    -   requesting the execution of configuration checks or functional        checks that exhaustively verify the behavior of the nodes, or        requesting network functional checks and visualizing the        outcomes obtained in the form of reports.

Each of the stations U1, . . . , Un is also able to start the simulationto verify a determined functionality of a node.

In the currently preferred embodiment of the invention, the stations U1,. . . , Un also have the ability to simulate in step-by-step mode thegeneric function of the node undergoing verification.

All this is done in an environment that allows one to:

-   -   select the node or nodes of interest;    -   select the analyzer of interest,    -   configure the input data of the analyzer,    -   configure (in transparent fashion for the user) the analyzer        exploiting the configuration data from the corresponding        printout,    -   simulate (possibly with step-by-step mode) the related function,        and    -   analyze the results of the analysis.

To enable the simulation of the complete behavior based on theconfiguration data present for a certain network service, an environmenthas been defined that allows one to: select a traffic scenario, astarting system and setting determined initial simulation conditions;display all possible alternatives obtained by simulating the differentnodes and the different interfaces that under any network condition willlead to the rendering of the service given the initial conditions set.

The stations U1, . . . , Un are usually able to simulate the effect ofthe application of a set of commands for updating the configurationdata, creating a new version of the configuration itself whereon can beexecuted simulations, checks and analyses before the actual modificationof the data on the nodes of the actual network.

Naturally, without changing the principle of the invention, therealization details and the embodiments can be widely varied withrespect to what is described and illustrated herein, without therebydeparting from the scope of the present invention.

1. A method for controlling the configuration of elements of atelecommunications network comprising a plurality of nodes, the methodcomprising the steps of: generating a model configuration of saidelements comprising, for at least one function of each element subjectedto control, a respective model of implementation of the function itself,collecting, for each element subjected to control, at least onerespective set of configuration data of the element itself, verifying,for each element subjected to control and in the absence of interactionwith the element itself correspondence between said at least onefunction as implemented on the basis of said at least one respective setof configuration data of the element and said model of implementation ofthe function itself included in said model configuration, and performingthe steps of generating a model configuration, collecting said at leastone respective set of configuration data of the element and verifyingsaid correspondence in relation with at least one of the groupincluding: an interfacing element between two nodes of said plurality,and a plurality of respective sets of configuration data of saidelement, said plurality of respective sets of configuration dataexpressing respective different configuration states of the element. 2.The method as claimed in claim 1, further comprising the steps of:simulating on the basis of said at least one set of configuration dataof the element and in the absence of interaction with the elementsubjected to control the implementation of said at least one function bygenerating at least one respective outcome of implementation of thefunction itself through the element subjected to control, and verifyingcorrespondence between said at least one respective outcome ofimplementation obtained by simulation and the correspondingimplementation model included in said model configuration.
 3. The methodas claimed in claim 2 wherein said simulating step is performed on thebasis of at least one respective set of analysis functionsrepresentative of a respective element model.
 4. The method as claimedin claim 2 wherein said simulating step is conducted step-by-step. 5.The method as claimed in claim 1, further comprising the step ofselecting said plurality of respective sets of configuration data asexhaustive representation of the configuration states allowed for saidelement.
 6. The method as claimed in claim 1, further comprising thestep of modifying the configuration data included in said at least onerespective set of configuration data of each element subjected tocontrol in order to obtain the correspondence between the actualconfiguration of the element and said model configuration.
 7. The methodas claimed in claim 1, further comprising the step of selecting saidmodel configuration as representative of at least one of the groupincluding: a set of configuration data meant to be identical on allhomologous elements of the network in the cases of configurationcontrol; a set of expected behaviors for an element in the case offunctional analysis; and a set of exhaustive behaviors of all elementsable to be traversed in the case of simulation of a determined servicethroughout the network.
 8. The method as claimed in claim 1, furthercomprising the step of providing a control management station for thegeneration of said model configuration.
 9. The method as claimed inclaim 1, further comprising the step of providing a plurality of controlstations able to start the execution of said verifying step.
 10. Themethod as claimed in claim 1 wherein at least one of said steps ofgenerating, collecting, simulating, verifying and modifying isconfigured to be performed in a centralized position with respect tosaid elements subjected to control.
 11. A system for controlling theconfiguration of elements of a telecommunications network comprising aplurality of nodes, the system comprising: a database containing a modelconfiguration of the elements of said network and comprising for atleast one function of each element subjected to control a respectivemodel of implementation of the function itself, for each elementsubjected to control at least one respective set of configuration dataof the element itself, for each element subjected to control averification module to verify in the absence of interaction with theelement itself correspondence between said at least one function, asimplemented on the basis of said at least one respective set ofconfiguration data, and said model of implementation of the functionitself included in said model configuration, and a model configurationas well as a set of configuration data to allow the verification by saidverification module in relation with an interfacing element between twonodes of said plurality or a plurality of respective sets ofconfiguration data of said element, said plurality of respective sets ofconfiguration data expressing respective different configuration statesof the element.
 12. The system as claimed in claim 11, furthercomprising: a simulation module to simulate based on said at least onerespective set of configuration data of the element and in the absenceof interaction with the element subjected to control, the implementationof said at least one function and generating at least a respectiveoutcome of implementation of the function itself by the elementsubjected to control, said verification module being configured toverify the correspondence between said at least one respective outcomeof implementation obtained by simulation and the correspondingimplementation model included in said model configuration.
 13. Thesystem as claimed in claim 12 wherein said simulation module comprises arespective set of function for the simulation of respective functions.14. The system as claimed in claim 12 wherein said simulation moduleoperates according to step-by-step simulation modes.
 15. The system asclaimed in claim 11 wherein said verification module is configured tooperate on a plurality of respective sets of data constituting anexhaustive representation of the allowed configuration states for saidat least one element subjected to control.
 16. The system as claimed inclaim 11 wherein the system itself is configured to modify the dataincluded in said at least one respective set of configuration data ofeach element subjected to control in order to obtain the correspondencebetween the actual configuration of the element and said modelconfiguration.
 17. The system as claimed in claim 11 wherein saiddatabase contains a model configuration representative of at least oneof the group including: a set of configuration data that it is requiredbe identical on all the homologous elements of the network in the casesof configuration controls; a set of expected behaviors for an element inthe case of functional analyses; and a set of exhaustive behaviors ofall elements that can be traversed in the case of simulation of adetermined service throughout the network.
 18. The system as claimed inclaim 11, further comprising a control management station for generatingsaid model configuration.
 19. The system as claimed in claim 11, furthercomprising a plurality of control stations able to drive saidverification module.
 20. The system as claimed in claim 11 wherein saiddatabase or said verification module is located in a centralizedposition relative to said elements subjected to control.
 21. A computerreadable medium having computer-executable instructions stored thereonwhich, when executed by at least one digital computer, implement themethod as claimed in claim 1.